Table of Contents
This chapter discusses the creation and management of volumes.
A volume is a file system that holds user data and is accessible to clients through a virtual server that is configured with one or more access protocols such as NFS and CIFS. A volume in Data ONTAP 10.0 is equivalent to a flexible volume in Data ONTAP 7.x. Other data entities in Data ONTAP 7G or earlier, including traditional volumes and qtrees, are not supported in Data ONTAP 10.0.
A volume is the basic unit of storage on a Data ONTAP 10.0 system; it provides a conceptual container for a set of logically related directories and files. Volumes create a single logical storage area that can be seamlessly managed across diverse platform types and geographically dispersed locations. The global namespace for a virtual server is created by mounting volumes to the virtual server's root volume and to one another. You mount volumes by using junctions, which are similar to UNIX mount points. A junction from one volume to another can be active (that is, the volume appears in the global namespace) or inactive (that is, any volume without an active junction does not appear in the global namespace).
You can perform the following operations on volumes:
A Snapshot™ of a volume is located on the parent volume but has read-only access. It represents the contents of the original volume at a particular point in time. A parent volume and a Snapshot of it share disk space for all blocks that have not been modified between the creation of the volume and the time the Snapshot is made, thereby making Snapshots lightweight. Similarly, two Snapshots share disk space for those blocks that were not modified between the times that the two Snapshots were created. A chain of Snapshots can be created to represent the state of a volume at a number of points in time. Snapshots can be accessed online, enabling users to retrieve their own data from past copies, rather than asking a system administrator to restore data from tape. Administrators can restore the contents of a volume from a Snapshot.
Each volume has a .snapshot directory that is accessible to NFS users by using the ls command and to CIFS users by double-clicking the ~snapshot folder. The contents of the .snapshot directory are a set of subdirectories, labeled by type, date, and time, resembling the following:
$ls .snapshotdaily.2006-05-14_0013/ hourly.2006-05-15_1306/ daily.2006-05-15_0012/ hourly.2006-05-15_1406/ hourly.2006-05-15_1006/ hourly.2006-05-15_1506/ hourly.2006-05-15_1106/ weekly.2006-05-14_0019/ hourly.2006-05-15_1206/
Each subdirectory of the .snapshot directory includes a list of the parent volume's files and directories. If users accidentally delete or overwrite a file, they can locate it in the most recent Snapshot directory and restore it to their main read-write volume simply by copying it back to the main directory. The following example shows how an NFS user can locate and retrieve a file named my.txt from the .snapshot directory:
$ls my.txtls: my.txt: No such file or directory$ls .snapshotdaily.2006-05-14_0013/ hourly.2006-05-15_1306/ daily.2006-05-15_0012/ hourly.2006-05-15_1406/ hourly.2006-05-15_1006/ hourly.2006-05-15_1506/ hourly.2006-05-15_1106/ weekly.2006-05-14_0019/ hourly.2006-05-15_1206/$ls .snapshot/hourly.2006-05-15_1506/my.txtmy.txt$cp .snapshot/hourly.2006-05-15_1506/my.txt .$ls my.txtmy.txt
Note that, unlike in Data ONTAP 7G or earlier, the .snapshot directory is always visible and available from within the volume, and not visible but still available from any other volume. In Data ONTAP 7G or earlier, you can customize the behavior of the .snapshot directory.
You can move a volume from one aggregate or node to another. The original volume is completely copied to the new location with the same name and junction, and then the original volume is deleted. This feature is useful for space management and load balancing. For instance, if one aggregate holds 500 volumes with similar sizes and another aggregate of the same size holds only 200 volumes of the same approximate sizes, you can move volumes from the first aggregate to the second to balance the load and improve performance. A volume move must occur within the context of the same virtual server.
A volume copy is a full copy of the original volume with the same access (read-only or read-write) as the original volume. It does not share blocks with the original volume; thus, a copy of a 2-GB volume uses 2 GB of disk space, unlike a Snapshot of a volume, which might use only a few kilobytes of disk space because of shared blocks. After the copy is made, no operations made on the copy or on the original affect the other. For instance, if you write data to the original volume, the data is not written to the copy. A volume copy is not automatically mounted when it is created. A volume copy must occur within the context of the same virtual server.
A volume mirror is a read-only copy of a volume on the same or a different aggregate. It does not share blocks with the original volume. It can be synchronized with the original volume whenever the administrator desires or set to be automatically synchronized on a defined schedule. Data ONTAP 10.0 mirrors are asynchronous, not synchronous. After a volume mirror is created, it must be replicated with data from the original volume before it is ready for use. There are two types of mirrors, load sharing (LS) and disaster recovery (DR). An LS mirror is mounted in the same area of the name space as its parent volume to provide additional read-only access to multiple clients. A DR mirror is mounted in a different area of the name space from the parent volume; it can be used as a mirror at a remote site across a WAN. If the WAN link becomes unavailable, the DR mirror remains available at the remote site. If the parent volume is lost, either type of mirror can be promoted to be the parent volume. A volume mirror must occur within the context of the same virtual server.
A mirror's location in the global namespace depends on its type:
An LS mirror is read-only and is automatically mounted with the same mount path as the parent read-write volume; if a read-write volume has one or more LS mirrors, client requests are automatically routed to the LS mirror or mirrors to reduce the load on the parent read-write volume. This is useful for frequently read but infrequently updated data such as shared binary files; you can, for instance, set up one or more LS mirrors to a volume that is mounted at the directory /bin, and client requests to read the binaries on that volume are typically routed to the LS mirrors, not to the parent read-write volume.
A DR mirror is read-only. It must be mounted at a different location from its parent volume.
If you promote a mirror to be the parent volume, it assumes the parent volume's location, so clients can continue to read and write to it.
If you are mounting a volume that has one or more LS mirrors from a client that must have access to the parent read-write volume (for instance, to make changes to it), you must mount it through the .admin link at the root of the virtual server. The /.admin link routes requests to the parent read-write volume regardless of whether the volume has any mirrors. For example, if you are mounting a client that requires read-write access to a mirrored volume mounted at /dept/eng/sandbox on a virtual server named engdata, use the following command:
#mount -t nfs engdata:/.admin/dept/eng/sandbox
If you are mounting a client that does not require read-write access to the same volume, use the following command:
#mount -t nfs engdata:/dept/eng/sandbox
If you create or mount a new volume on a mirrored parent volume, or delete or unmount a volume from a mirrored parent volume, be sure to manually replicate the parent volume's mirror or mirrors. Failure to do so has the following results:
If you create or mount a new volume on a mirrored parent volume without replicating the parent volume's mirror or mirrors, the new or mounted volume is not visible unless you access it through the /.admin link.
If you delete or unmount a volume on a mirrored parent volume without replicating the parent volume's mirror or mirrors, a client can hang if it attempts to do a directory listing of the parent volume.
Mirroring requires a separate license; contact your sales or support representative for details.
The following limitations apply to mirrors:
If a read-write volume has no LS mirrors, you can mount it normally and client requests are always directed to it. However, as soon as an LS mirror is created for a read-write volume, client requests are directed to the LS mirror or mirrors. If a client requires read-write access to a read-write volume that has one or more LS mirrors, you must mount it through the /.admin link at the root of the virtual server, as described in the previous section.
Although a parent read-write volume can have both LS and DR mirrors, mirror volumes cannot be mirrored. For example, you cannot create an LS mirror of a DR mirror or a DR mirror of an LS mirror unless one mirror is first promoted to be the parent read-write volume.
The following table summarizes the differences among Snapshots, copies, mirrors, and moved volumes.
Table 11.1. Differences Among Volume Features
| Feature | Access type (read-write or read-only) | Auto-mounted? | Full copy or shared blocks? | Location |
|---|---|---|---|---|
| Snapshot | Read-only | Yes | Shared blocks (same volume as parent) | Same aggregate and node |
| Copy | Same as the original volume (read-write or read-only) | No | Full copy | Same or different aggregate; same or different node |
| Mirror | Read-only | No | Full copy | Same or different aggregate; same or different node |
| Move | Same as the original volume (read-write or read-only) | Yes | Full move, then deletion of original | Different aggregate; same or different node |
All of these volume operations must occur within the context of the same virtual server. For instance, you cannot move a volume from a virtual server named vs0 to a virtual server named vs1. However, a virtual server can span multiple nodes and multiple aggregates.
You can schedule regular occurrences of Snapshots and mirrors by creating schedules. See Chapter 13, Managing Jobs and Schedules for information on creating schedules.
Volume operations can take a long time to complete, depending on the size of the volume and the load on the cluster. For instance, moving a 1-TB volume might take several hours to complete. See Chapter 13, Managing Jobs and Schedules for information on managing long-running jobs.
Each volume must be labeled with a name that is unique to its virtual server; you use this name in commands to manage the volume. You need to give some thought to the names you choose so that when other volumes are added to the virtual server, the names are orderly and recognizable. For example, if you are deploying a software-development project on a Data ONTAP 10.0 system, you might choose to create the following volumes:
A volume named user_user_name for each user
A volume named src_component for source code for each component
A volume named build_component for compiled images of each component
Uniform naming schemes make it easier to manage large number of volumes.
Volume names must conform to the following rules:
The first character in the volume name must be an alphabetic character (a to z or A to Z).
Characters in a name can include alphanumeric characters (a to z, A to Z, and 0 (zero) to 9) and the underscore character (_). Other characters and symbols are not permitted.
Volume names can be from 1 to 203 characters in length. If a volume name exceeds 203 characters in length, Snapshots, mirrors, and striped volumes do not work correctly.
The root volume for a virtual server is automatically created and mounted when the virtual server is created. The root volume is given the name specified by the value of the -rootvolume parameter of the vserver new command; see “Creating a Virtual Server” for details. The volume is mounted at / (root).
Up to 500 volumes can be created on each node in a cluster; if more than one storage aggregate is located on a particular node, the total number of volumes on those aggregates cannot exceed 500.
This limit assumes that you are using storage failover (SFO). If you are not using SFO, up to 1,000 volumes can be created per node; however, without SFO, those volumes become unavailable if the node fails.
A cluster can contain up to 60,000 volumes and Snapshots. Be sure to account for all Snapshots as well as their parent volumes when tracking the total number of volume and Snapshots in your cluster.
A volume can contain up to 100,000 directories; however, two of these directories are links to the current directory (.) and the parent directory (..), so the effective limit is 99,998 directories per volume.